Dynamic multipoint virtual private networks (DMVPN) are increasingly popular among network operators. In a DMVPN, the members of a virtual private network (VPN) can communicate with each other in an any-to-any fashion over an Internet Protocol (IP) cloud. This any-to-any communication only requires the IP cloud to be able to unicast, even to support both unicast and multicast among the VPN members. DMVPN uses IP tunneling techniques including generic routing encapsulation (GRE) to tunnel the VPN traffic through shared network infrastructure including, for example, the Internet. An IP tunnel between two spoke routers may be created on an as-needed basis to directly exchange the data traffic. This alleviates the need for the hub router to route ‘unicast’ data between spoke networks. This need was common in a non-fully meshed frame relay topology, which resulted in a temporal full mesh logical topology for unicast data forwarding.
The desire to distribute content (e.g., video, audio, real-time meeting feeds) using multicasting is becoming more popular among DMVPN operators. In a conventional hub-and-spoke network configuration, multicasting between spokes typically includes sending all multicasting traffic, both control plane and data plane traffic, through the hub. In the context of DMVPN, this is due in part to the fact that the next hop routing protocol (NHRP) forces spokes to map outgoing multicast traffic to an NHRP server, which is typically implemented at the hub. At one time this was practical because the computer resources (e.g., processor power, bandwidth, memory) used in an NHRP server and multicast distribution point were limited and expensive. However, as resources become more available and/or less expensive, the rationale for routing all multicast traffic through a hub may no longer be compelling and even disadvantageous due to the added latency. Furthermore, it may no longer be reasonable to prohibit a hub-and-spoke network and/or a DMVPN implemented on a hub-and-spoke network from adopting a product independent multicast (PIM) source specific multicast (SSM) approach.
In a unicast situation, traffic from a first location that is intended for a second location may arrive at a spoke router. The second location may be associated with an IP address that lies beyond the spoke site. The fact that the IP address lies beyond the spoke site may trigger an address resolution action. In one example, if a route to the second location is already known and resolved, then the next hop and/or the corresponding resolved address may simply be looked up in a routing table, a routing information base (RIB), an NHRP database, and so on. However, if the route is not resolved, then an NHRP resolution action may be used to resolve the address. As addresses and routes are learned, data structures in routers may be updated with the acquired knowledge. In the unicast situation, at boot time, a spoke router only has knowledge of a hub. The spoke router only learns about other spokes when it receives traffic of interest. This traffic of interest may lead to a spoke router becoming aware of the IP address of other spokes. These addresses may be stored in a knowledge base (e.g., table) of IP addresses.
In a multicast situation, a receiver may wish to signal its desire to receive content for a multicast group or channel from a sender. Multiple receivers may wish to receive content from the sender. For example, audio and video of a real-time shareholder's meeting may be available from a sender. Many receivers (e.g., shareholders) may wish to receive this audio and video. A computer associated with a receiver may send a Join Group message to its spoke router. Conventionally, the spoke router may have taken actions associated with unicast traffic to establish a route from the sender to the receiver. Typically, these actions included resolving an address using a reverse path forwarding (RPF) check. Resolving the address for multicast using this unicast approach has typically not included triggering an NHRP action. Instead, the resolving has simply involved finding a route that traversed the hub using unicast tables. Therefore, spoke-to-spoke multicast traffic typically included the hub, resulting in a hub-and-spoke logical topology for multicast data forwarding.